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INTRODUCTION 

Researchers conducting experiments with flight simulators 
encounter numerous obstacles in bringing their ideas to the simulator. 
This paper reports on research into how these simulators could be used 
more efficiently. The study involved: (1) analyzing the Advanced 

Concepts Simulator software architecture, (2) analyzing of the 
interaction between researchers and simulation programmers, and (3) 
proposing a documentation tool for researchers. 

DISCUSSION 

I. Analysis of the Advanced Concepts Simulator Software Architecture 

The Advanced Concepts Simulator (ACS) is designed to model flight 
station concepts for a 1995 transport aircraft. The ACS provides a 
platform for research into a wide variety of flight management systems 
technologies and pilot/cockpit interfaces. The implementation of the 
ACS involves about a dozen computers and nearly one million lines of 
software. The first use of this simulator is scheduled for 1991. 

Given that the normal mode of use for a flight simulator is to 
change an aircraft subsystem and gather performance data from that 
change, it is imperative that a simulator be modifiable. The 
following recommendations are made for changes to the ACS software in 
order to accommodate modifiability: (1) in the short term, substan- 

tially reduce the number of global variables, repartition some of the 
software modules, and produce up-to-date system documentation, and 
(2) in the long term, move to modern software engineering technologies 
(i. e.. Computer Assisted Software Engineering tools for real-time 
systems, object oriented approaches, etc.). 

II. Analysis of the Interaction Between Researchers and Flight 
Simulation Systems 

Researchers' interaction with simulation systems is unique. 
Researchers are not system "users" in the traditional sense (pilots 
are the "users") ; researchers are not "programmers" or "analysts" 

(even though much of the work involves programming and systems 
analysis) . The interaction between researcher and simulator is 
described in Figure 1. Analysis of this interaction revealed four 
problem areas: 

1. Design Specifications -- Many research projects involve complex 
algorithms and/or pilot-cockpit interfaces. Producing specifi- 
cations for the programmers is extremely complex and expensive. 
Researchers and programmers often engage in a protracted process 
of exchange and compromise before a display design is completed. 
Another approach has the researcher actually programming the 
system on a PC and the program becomes the specification to the 
simulator programmers. 
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2. Simulator Documentation -- No accurate documentation on how the 
simulator works is currently available. Researchers generally 
agree that having information about what models are used within 
the simulator, data flow between modules, and how modules are 
organized could be of great benefit. 

3. Pilot Orientation — Briefing manuals for other simulators have 
been developed; however, pilot orientation will be more extensive 
on the ACS in order for the pilot to become acquainted with the 
"advanced concepts" . 

4. Researcher Collaboration — In conducting an experiment, a 
researcher produces much "informal results" for which there is no 
forum currently available. 

III. A Proposal for a Documentation Tool for Researchers 

A documentation tool which addresses the four problems listed 
above must have the following characteristics: accurate, easily (or 

automatically) updated, well organized, provide rich means for access 
to the information, easy to use, encompass a variety of types of 
information, help generate ideas, flexible/robust — easily adapted 
for unplanned uses, improve with use, and encourage active participa- 
tion (researchers contribute as well as receive information) . Also, 
for such a tool to be effective researchers must be committed to 
contributing to the information base ("I Know" becomes "We Know") . 

To address these required characteristics, a documentation tool 
has been proposed and a preliminary implementation has been performed. 
The documentation tool is a hypertext which contains the information 
about flight crew orientation, flight crew displays, data flow within 
the simulator, module hierarchy, what variables can be set by the 
researcher, what data can be automatically collected, researcher 
notes, simulation limitation, and planned modifications to the 
simulator. The tool provides for prototyping of cockpit displays 
which can be used as design specifications, pilot o rien t a tion 
materials, and description to other researchers in future experiments. 
Also, the tool includes management of researcher notes which can serve 
as a means to disseminate formal and informal results. 

CONCLUSION 

The following conclusions have been drawn from this research: 

1. Effort must be devoted to "cleaning up" and documenting the ACS. 

2. Communication between researchers and the simulation system is a 
major problem. 

3. Communication among researchers of "informal results" is limited. 

4. Hypertext can be used to facilitate researcher activities by 
providing prototyping, specification, and documentation of flight 
crew displays, facilitating communication among researchers, and 
providing access to information about how the simulator is 
implemented. 

A plan for creating the documentation tool described here should 
include: formal design of the tool, implementation, and validation of 

the tool by using it in conjunction with a research project on the 
ACS . 


108 



Pilot 





Simulation 

What the Researcher wants ? 



Information Flow Between the Researcher 
and the Simulation System 

Figure l 

109 



